Description

is_email( 'abc..def@xyz.com' ) returns the address as valid, even though the local part contains consecutive dots. PHP's filter_var( …, FILTER_VALIDATE_EMAIL ) rejects it, and so does every SMTP server, because the address is undeliverable. The same applies to a leading dot (.abc@xyz.com) and a trailing dot (abc.@xyz.com).

Since [62225]/#31992, is_email() delegates to WP_Email_Address::from_string(), whose local-part patterns are derived from the WHATWG <input type=email> character set. That set places . in the character class with no positional constraint ([…]+), so any arrangement of dots passes. The domain side already validates correctly (each label must be bookended by an alphanumeric), so this only affected the local part.

This PR restructures the local part as a proper dot-atom, mirroring the existing domain-label design already in the class: a dot may only separate non-empty atoms. Leading, trailing, and consecutive dots are now rejected, while all previously valid addresses — including the intended Unicode addresses from #31992 (grå@grå.org) — continue to validate.

Why reject these

This change is not a departure from #31992 — it implements a decision that ticket's discussion already reached. While reviewing test cases on #31992, @agulbra noted:

to..to@couc.ou and to.@couc.ou are invalid according to RFC 5321, therefore WordPress cannot send mail to them. Rejecting these is a good idea.

and @peteresnick — the author of RFC 5322 — confirmed:

Also invalid according to 5322 section 3 (the more restrictive) syntax.

The WHATWG character set was adopted as the basis for the allowed characters, but the agreed intent was to be at least as strict as the syntaxes used to generate and deliver mail, which forbid empty atoms in the local part. The shipped regex used the WHATWG […]+ shorthand verbatim and did not enforce that structure; this PR closes that gap.

Implementation

• Add LOCAL_PART_ATOM_ASCII and LOCAL_PART_ATOM_UNICODE constants (the previous local-part character sets, minus the dot).
• Assemble LOCAL_PART_ASCII_REGEX / LOCAL_PART_UNICODE_REGEX as atom (?:\. atom)*, the same dot-separated structure already used by DOMAIN_ASCII_REGEX / DOMAIN_UNICODE_REGEX.

Testing instructions

1. Apply the patch.
2. Confirm the following now return false:

   is_email( 'abc..def@xyz.com' ); // consecutive dots
   is_email( '.abc@xyz.com' );     // leading dot
   is_email( 'abc.@xyz.com' );     // trailing dot

3. Confirm normal addresses still validate:

   is_email( 'bob@example.com' );
   is_email( 'bill+ted@example.com' );
   is_email( 'a.b.c@example.com' ); 
   is_email( 'grå@grå.org' );

4. Or run the test suite:

   npm run test:php -- --group 55821
   npm run test:php -- --filter 'IsEmail|EmailAddress|Antispambot|SanitizeEmail'

Unit tests

• tests/formatting/isEmail.php: Moved ..@example.com from the valid provider to the invalid provider, added the leading/trailing/consecutive-dot cases, and tagged the test with @ticket 55821.
• tests/wp-email-address/wpEmailAddress.php: New @ticket 55821 test asserting rejection in both unicode and ascii modes.
• tests/formatting/antispambot.php: Relabeled a now-inaccurate data-set key (antispambot() is obfuscation-only; behavior unchanged).

Trac ticket: https://core.trac.wordpress.org/ticket/55821

Use of AI Tools

AI assistance: Yes — used to investigate the regression, cross-reference the #31992 discussion, draft the fix, and write the tests. All changes were reviewed and verified by me.